LTE, or Long Term Evolution, is a name for research and development involving the Third Generation Partnership Project (3GPP), to identify technologies and capabilities that can improve systems such as the UMTS. A current working assumption for LTE is that users are explicitly scheduled on a shared channel every transmission time interval (TTI) by an eNodeB. An eNodeB is an evolved Node B and is the UMTS LTE counterpart to the term “base station” in the Global System for Mobile Communication (GSM). In order for a transmitter and/or receiver, such as a user equipment terminal (UE), to communicate with the other network elements involved in UMTS LTE, the transmitter and/or receiver must be able to support the functionality and meet the performance requirements necessary to participate in UMTS LTE. In certain circumstances, evolving improvements to a communication system may require existing devices to support the services and functions related to the improvements. For example, radio frequency and performance testing may be performed on transmitters and/or receivers in order to determine whether the transmitters and/or receivers have the capabilities required for UMTS LTE services and/or newly provided technologies and capabilities based on continuing research and development aimed at improving communication systems.
E-UTRAN is a packet-based system, and it is likely that under test conditions data rates may vary between the downlink and uplink. Therefore, test situations may arise where the transmitter and/or receiver, i.e. UE, that is being tested may encounter unspecified situations as a result of the difference in data rates between the uplink and downlink. For example, if the downlink data rate is greater than the uplink data rate due to current radio conditions or system commands then the UE or test device, i.e. system simulator (SS), may have more data packets than it can handle and may not be able to meet the specified requirements for the testing, for example returning packets within a specified time. This may lead to unspecified behavior in the UE or test device. This unspecified behavior may prevent the testing from being completed, or produce inaccurate or inconsistent test results. A similar situation may arise if the UE or test device is able to transmit more data than is received.
For example, high speed uplink packet access (HSUPA) is a 3GPP access technology aimed at increasing capacity and throughput on the uplink channel, while also reducing delay. In order to accomplish this, HSUPA includes an enhanced dedicated channel (E-DCH), which is intended to enhance the uplink channel. HSUPA and E-DCH are discussed in 3GPP TS 25.309 FDD Enhanced Uplink; Overall description; Stage 2 (Release 6) (2006-03), which is hereby incorporated by reference in its entirety. However, user equipment terminals (UE) must support E-DCH and meet the performance requirements defined for E-DCH in 3 GPP TS25.101 User Equipment (UE) radio transmission and reception (FDD) (Release 7) (2006-10) and 3GPP TS25.133 Requirements for support of radio resource management (FDD) (Release 7) (2006-10) in order to take advantage of this technology, which are hereby incorporated by reference in their entirety. Therefore, a UE must be tested in order to determine whether the particular UE is capable of supporting E-DCH and meeting the performance requirements. The testing of a particular UE may focus on radio frequency and performance testing. Test methods used to verify that a transmitter and/or receiver, i.e. UE, has the characteristics required to support E-DCH, and is capable of receiving downlink E-DCH channels are specified in 3GPP TS 34.121-1 User Equipment (UE) conformance specification; Radio transmission and reception (FDD); Part 1: Conformance specification (Release 7) (2006-10), which is hereby incorporated by reference in its entirety.
The E-DCH downlink channels include E-DCH absolute grant channel (E-AGCH), E-DCH relative grant channel (E-RGCH) and E-DCH hybrid ARQ indicator channel (E-HICH). E-HICH is a downlink physical channel that is used by the hybrid automatic repeat request (HARQ) process to acknowledge E-DCH transmissions from the UE. E-AGCH is a shared downlink channel that is used to indicate to the UE how much data can be sent on the uplink, allowing the UE to determine the E-DCH traffic format combination (TFC) and maximum allowed power. E-RGCH is a shared downlink channel that is used to decrease or increase the uplink resources compared to the previously used value. Even though E-DCH is designed as an uplink enhancement, the UE must be capable of receiving downlink E-DCH channels because these feedback channels are required to indicate which data rates the UE has been scheduled to use (E-AGCH, E-RGCH), and to indicate whether the network has successfully received a transmission from the UE (E-HICH). During testing to determine whether a particular UE can receive downlink E-DCH channels, and in some uplink test cases, the UE has to generate data for its uplink E-DCH data and control channels However, test methods available in 3GPP TS 34.109 Terminal logical test interface; Special conformance testing functions (Release 6) (2006-09) which is hereby incorporated by reference in its entirety, are insufficient to enable reliable transmission on the uplink E-DCH channel during the testing.
Previously defined test cases such as those for release 99 DCH in 3GPP use either a UE loop back mode 1 or 2 test. Loop back modes 1 and 2 are discussed in 3GPP TS 34.109 Terminal logical test interface; Special conformance testing functions (Release 6) (2006-09). As stated previously, E-DCH conformance testing requires that the UE under testing has data to transmit over the uplink channel in its E-DCH dedicated physical data channel (E-DPDCH). E-DPDCH is used to carry the E-DCH data transport channel. However, during the testing the data rate at which the UE under test may be allowed to transmit on the uplink can vary due to absolute and relative grants that the UE receives from a tester, for example a system simulator (SS), and retransmissions due to the uplink HARQ procedures.
UE test loop function may be used for testing of receiver characteristics based on BER (Bit Error Ratio) measurement. The SS calculates BER from a bit-by-bit comparison of data sent to and received from UE. BER measurement requires symmetric radio access bearer (RAB) bit-rates. The UE test loop function may also be used for testing of receiver performance based on BLER (BLock Error Ratio) measurement. The SS calculates BLER based on the RLC STATUS SDU received from the UE operating in RLC acknowledged mode; or the SS calculates BLER based on checking returned downlink data and downlink CRC by UE operating in UE test loop mode 2. The UE test loop function may also be used for testing of UE Blind Transport Format Detection, testing of UE transmitter characteristics, testing of UE transmitter DTX characteristics, and/or testing of radio bearers (RB), for example the UE test loop function emulates terminal equipment.
Test methods such as those previously defined for testing release 99 DCH in 3GPP in 34.109 Terminal logical test interface; Special conformance testing functions (Release 6) (2006-09), where the data received on the downlink is looped directly back to the uplink have been shown to be insufficient for testing due to the varying data rate that may occur during testing, and because the UE being tested should always have data to transmit in the uplink E-DCH. Loop back mode 1 in TS 34.109 (2006-09) was designed for continuous and fixed downlink and uplink data transfer, where the UE has a certain time to loop back the downlink data to uplink channels, i.e. loop back delay. Loop back delay is the delay between received downlink radio frames and their corresponding uplink radio frames produced from the received data.
For example, in FIG. 5.3.2.9.1 of 3GPP TS 34.109 (2006-09) the latest allowed transmission of a corresponding radio from the user equipment is 10 radio frames. When the uplink data rate varies, for example due to system conditions or commands, it is impossible for the UE being tested to guarantee the fixed loop back delay required. In addition, when the uplink data rate on E-DCH is smaller than the downlink data rate on high speed downlink packet access (HSDPA) channel the packets are buffered by the UE. However, in this situation when the buffers are filled the UE behavior is unspecified, which typically may result in the UE resetting and therefore not completing the testing. It appears that UE buffer overflows cannot be avoided by balancing the downlink data rate with the uplink data rate. If this approach was used using the test methods discussed in TS 34.109 (2006-09) the loopback of data to the E-DCH may not occur or may be otherwise inconsistent.
Testing to determine whether a UE supports E-DCH and meets the performance requirements is just one example in which testing UE capabilities may result in unfavorable or inconsistent results due to the varying transmission rates on uplink and downlink channels. Similar situations may arise during testing of E-UTRAN uplink and feedback transmitted on the downlink related to the uplink in which test methods are insufficient to provide accurate and complete results.
Therefore, what is needed is a test that is suitable for testing transmitter and/or receiver capabilities and performance, for example to determine whether the transmitter and/or receiver supports a particular access technology (i.e. E-DCH), where test conditions may include variable data rates on both uplink and downlink channels. In particular, what may be needed is a way to generate reliable data transmission flow on E-DPDCH for E-DCH testing.